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APPARATUS AND METHOD FOR VERIFYING CATEGORIZATION OF SERVICES 
USING CANONICAL SERVICE DESCRIPTION TESTS 

RELATED APPLICATIONS 

This application is related to similar subject matter as co- 
pending and commonly assigned U.S. Patent Application Serial Nos. 

(Attorney Docket No. RSW9-2000-0101) entitled 

"APPARATUS AND METHOD FOR E-BUSINESS SERVICE BROKERAGE", filed 

' (Attorney Docket No. RSW9-2000-102) entitled 

"APPARATUS AND METHOD FOR CATEGORIZATING SERVICES USING CANONICAL 

SERVICE DESCRIPTIONS", filed on even date herewith, and 

(Attorney Docket No. RSW9-2000-104) entitled "SERVICE TAXONOMY 
CRAWLER APPARATUS AND METHOD", filed on even date herewith, each 
of which are hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 

1. Technical Field: 

The present invention is directed to an apparatus and method 
for categorizing services using canonical service descriptions. 
More specifically, the present invention is directed to an 
apparatus and method for electronic business (e-business) service 
categorization for use with an electronic service broker in order 
to place e-business services into categories within taxonomies 
that are searchable at run time. 

2. Description of Related Art: 

A world in which a myriad of e-business services connect and 
collaborate with one another over the Internet is fast becoming a 
reality. Business- to-business (B2B) service interactions already 
exist using a variety of schemes that range from very rigid 
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point-to-point Electronic Data Interchange (EDI) interactions to 
open Web auctions, e.g., Ariba, Chemdex, eSteel, and eBay. 
Thousands of businesses have already made some of their IT 
services available to their customers or partners on the Web. 
Most of these services are intended for use from a browser. But 
with technology such as WIDL from webMethods 

(www.webmethods.com) , many of the Web-enabled services can also 
participate in B2B collaborations. 

Known e-business services collaborate without any 
overarching vision or architecture. Techniques for B2B 
collaboration vary from one case to another. As the number and 
type of e-business services grows, the ability of an e-business 
consumer to locate and contact a provider of an e-business 
service will become increasingly difficult. Today, there is no 
vendor neutral archtectural mechanism for classifying e-business 
services such that an e-business service consumer can locate and 
contact a provider of a desired e-business service. Thus, it 
would be beneficial to have an apparatus and method for 
classifying services in such a manner as to make them searchable 
and usable at run-time. 
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SUMMARY OF THE INVENTION 



The present invention provides an apparatus and method for 
service classification verification. The present invention makes 
use of canonical service description tests which designate 
minimum requirements for a service to be classified into a 
corresponding classification. Based on the canonical service 
description tests, it can be determined whether a service that 
wishes to be classified into a pariticular classification of a 
taxonomy on a service broker meets the minimum requirements for 
that classification. Furthermore, the use of canonical service 
description tests ensures that all services classified into a 
particular classification have a minimum level of functionality 
that will allow them to function properly when invoked. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
5 however, as well as a preferred mode of use, further objectives 
and advantages thereof, will best be understood by reference to 
the following detailed description of an illustrative embodiment 
when read in conjunction with the accompanying drawings, wherein: 
Figure 1 is a diagram illustrating a distributed data 
10 processing system according to the present invention; 

Figure 2 is an exemplary block diagram of a server according 
to the present invention; 
jl Fxgure 3 is an exemplary block diagram of a client according 

^"-=1 to the present invention; 

;J5 Figure 4 is an exemplary block diagram illustrating the 

■|j interaction of e-business service consumers with e-business 

'■J: i 

service providers via a broker; 

Figure 5 is an exemplary diagram illustrating a canonical 

service description in accordance with the present invention; 
r^O Figure 6 is an exemplary diagram illustrating the 

registration of a service in multiple taxonomies of various 

service brokers; 

Figure 7 is an exemplary diagram illustrating the 

hierarchical levels traversed in a service broker to identify an 
25 e-business service provider in accordance with the present 

invention; 

Figure 8 is a flowchart outlining an exemplary operation of 
the present invention when registering a new service with a 
broker; and 

30 Figure 9 is a flowchart outlining an exemplary operation of 

the present invention when identifying an e-business service 
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provider based on the categorization of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



With reference now to the figures, and in particular with 
reference to Figure 1, a pictorial representation of a 
distributed data processing system is depicted in which the 
present invention may be implemented. Distributed data 
processing system 100 is a network of computers in which the 
present invention may be implemented. Distributed data 
processing system 100 contains network 102, which is the medium 
used to provide communications links between various devices and 
computers connected within distributed data processing system 
100. Network 102 may include permanent connections, such as wire 
or fiber optic cables, or temporary connections made through 
telephone connections . 

In the depicted example, server 104 is connected to network 
102, along with storage unit 106. In addition, clients 108, 110 
and 112 are also connected to network 102. These clients, 108, 
110 and 112, may be any type of computing device capable of 
sending and/or receiving information via the network 102. For 
example, the clients may be personal computers, network 
computers, personal digital assistants, Internet capable cellular 
telephones, and the like. For purposes of this application, a 
network computer is any computer coupled to a network which 
receives a program or other application from another computer 
coupled to the network. In the depicted example, server 104 
provides data, such as boot files, operating system images and 
applications, to clients 108-112. Clients 108, 110 and 112 are 
clients to server 104. Distributed data processing system 100 
may include additional servers, clients, and other devices not 
shown. 

In the depicted example, distributed data processing system 
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100 is the Internet, with network 102 representing a worldwide 
collection of networks and gateways that use the TCP/IP suite of 
protocols to communicate with one another. At the heart of the 
Internet is a backbone of high-speed data communication lines 
between major nodes or host computers consisting of thousands of 
commercial, government, education, and other computer systems 
that route data and messages. Of course, distributed data 
processing system 100 also may be implemented as a number of 
different types of networks such as, for example, an intranet or 
a local area network. Figure 1 is intended as an example and not 
as an architectural limitation for the processes of the present 
invention. 

Referring to Figure 2, a block diagram of a data processing 
system which may be implemented as a server, such as server 104 
in Figure 1, is depicted in accordance with the present 
invention. Data processing system 200 may be a symmetric 
multiprocessor (SMP) system including a plurality of processors 
202 and 204 connected to system bus 206. Alternatively, a single 
processor system may be employed. Also connected to system bus 
206 is memory controller/cache 208, which provides an interface 
to local memory 209. I/O bus bridge 210 is connected to system 
bus 206 and provides an interface to I/O bus 212. Memory 
controller/cache 208 and I/O bus bridge 210 may be integrated as 
depicted. Peripheral component interconnect (PCI) bus bridge 214 
connected to I/O bus 212 provides an interface to PCI local bus 
216. A number of modems 218-220 may be connected to PCI bus 216. 
Typical PCI bus implementations will support four PCI expansion 
slots or add-in connectors. Communications links to network 
computers 108-112 in Figure 1 may be provided through modem 218 
and network adapter 22 0 connected to PCI local bus 216 through 
add-in boards. Additional PCI bus bridges 222 and 224 provide 
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interfaces for additional PCI buses 226 and 228; from which 
additional modems or network adapters may be supported. In this 
manner, server 200 allows connections to multiple network 
computers. A memory mapped graphics adapter 23 0 and hard disk 
232 may also be connected to I/O bus 212 as depicted, either 
directly or indirectly. 

Those of ordinary skill in the art will appreciate that the 
hardware depicted in Figure 2 may vary. For example, other 
peripheral devices, such as optical disk drives and the like, 
also may be used in addition to or in place of the hardware 
depicted. The depicted example is not meant to imply 
architectural limitations with respect to the present invention. 
The data processing system depicted in Figure 2 may be, for 
example, an IBM RISC/System 6000, a product of International 
Business Machines Corporation in Armonk, New York, running the 
Advanced Interactive Executive (AIX) operating system. 

With reference now to Figure 3, a block diagram of a data 
processing system in which the present invention may be 
implemented is illustrated. Data processing system 300 is an 
example of a client computer. Data processing system 300 employs 
a peripheral component interconnect (PCI) local bus architecture. 
Although the depicted example employs a PCI bus, other bus 
architectures, such as Micro Channel and ISA, may be used. 

Processor 302 and main memory 3 04 are connected to PCI local 
bus 306 through PCI bridge 308. PCI bridge 308 may also include 
an integrated memory controller and cache memory for processor 
302, Additional connections to PCI local bus 306 may be made 
through direct component interconnection or through add- in 
boards. In the depicted example, local area network (LAN) 
adapter 310, SCSI host bus adapter 312, and expansion bus 
interface 314 are connected to PCI local bus 306 by direct 
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component connection. 

In contrast, audio adapter 316, graphics adapter 318, and 
audio/video adapter (A/V) 319 are connected to PCI local bus 306 
by add- in boards inserted into expansion slots. Expansion bus 
5 interface 314 provides a connection for a keyboard and mouse 
adapter 320, modem 322, and additional memory 324, 

In the depicted example, SCSI host bus adapter 312 provides 
a connection for hard disk drive 326, tape drive 328, CD-ROM 
drive 330, and digital video disc read only memory drive (DVD- 

10 ROM) 332. Typical PCI local bus implementations will support 
three or four PCI expansion slots or add-in connectors. 

An operating system runs on processor 302 and is used to 

^11 coordinate and provide control of various components within data 

yi processing system 300 in Figure 3. The operating system may be a 
commercially available operating system, such as Linux, which is 

gl available from International Business Machines Corporation, An 
object oriented programming system, such as Java (a trademark of 

[^1 Sun Corporation) , may run in conjunction with the operating 
system, providing calls to the operating system from Java 

i2p programs or applications executing on data processing system 300. 

'ri Instructions for the operating system, the object-oriented 

operating system, and applications or programs are located on a 
storage device, such as hard disk drive 32 6, and may be loaded 
into main memory 304 for execution by processor 302. 

25 Those of ordinary skill in the art will appreciate that the 

hardware in Figure 3 may vary depending on the implementation. 
For example, other peripheral devices, such as optical disk 
drives and the like, may be used in addition to or in place of 
the hardware depicted in Figure 3. The depicted example is not 

30 meant to imply architectural limitations with respect to the 
present invention. For example, the processes of the present 
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invention may be applied to multiprocessor data processing 
systems . 

The present invention provides an apparatus and method for 
categorizing services, e.g., e-business services, such that the 
categories of services may be searched to identify a supplier of 
a desired service. Based on the categorization of services, 
brokers may be established for providing a brokerage service to 
identify service providers. 

With the present invention, a service provider may register 
with one or more brokers to thereby publicize the availability of 
their services. When a service consumer wishes to make use of a 
service, the consumer contacts a broker, provides the criteria of 
the service desired, and instructs the broker to find a 
compatible provider of the desired service. The broker may then 
provide the service consumer with information indicating how to 
contact the service provider. 

Figure 4 is an exemplary block diagram illustrating the 
interaction of service consumers with service providers via a 
broker in accordance with the present invention. With the 
present invention, service consumer 410 is a requester of 
services, server providers 43 0-450 are suppliers of services, and 
broker 420 facilitates service consumers identifying compatible 
seirvice providers. 

The service consumer 410 may be any type of device that 
makes use of services available via the network 102. For 
example, the service consumer 410 may be a client device, such as 
client devices 108-112 in Figure 1. 

The description of the present invention refers to 
^^services^' which are requested by service consumers and supplied 
by service providers. The term "services'^ means any service that 
satisfies a business agenda of the service consumer. The 
"service" may collaborate with applications and services of other 
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consumers, providers, and organizations. A service may be, for 
example, credit card authorization, credit report ranking, 
printing a document, applying postage to the document, and any 
other service that may be provided or contracted for via a 
5 network. 

The service consumer 410 sends requests for services to the 
broker 42 0 via the network 102, The request is properly 
formatted so that the broker 420 may determine the category of 
service which is being requested by the service consumer 410. 
10 Based on the request and request parameters, the broker 420 
identifies one or more service providers that satisfy the 
request, if any compatible service providers are registered with 

,|| the broker 42 0, in a manner described hereafter. The service 

consumer may then select a service provider from those identified 

bJ5 and obtain, from the broker 420, information identifying the 

^ manner by which the service consumer may contact and obtain the 

4*^ requested service from the service provider. 

fj The service providers 430-450 may be implemented as any 

^ device coupled to the network 102 that is capable of providing or 

[go contracting for a service based on requests received over the 
network 102, The broker 420 is any type of device that is 
capable of receiving service requests from a service consumer 
410, identify a service provider that provides the requested 
service, and provides contact information to the service consumer 
25 via the network 102. The service providers 430-450 and the 
broker 42 0 may be implemented, for example, in a server 
apparatus, such as server 104. 

In order to maximize the benefit of services offered via a 
large and varying network environment, such as the Internet, a 
30 unified organizing principle must be adopted by which service 
consumers may be made aware of services that are available and 
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the providers of these services. The present invention provides 
an architecture by which services may be categorized in such a 
manner as to facilitate informing consumers of the availability 
of services and their providers. 
5 Categorization according to the present invention makes use 

of one or more taxonomies created and supported by each broker. 
The taxonomies are hierarchical in nature to reflect commonalties 
larger than the individual species. Just as with biological 
taxonomies, there is more than one way to categorize species of 
10 services and hence, there may be more than one possible taxonomy 
into which a service is classifiable. Because there may be many 
different possible taxonomies into which a service may be 
:r| classified, a service provider may need to register its services 
C| with multiple brokers, each broker supporting a different 
^$ taxonomy into which the service may be classified. 
i|| The service provider decides, at registration time, in which 

category, or categories, the service is to be registered. For 
example, if the service is air conditioning repair, the service 
j^i provider may decide to register the service in a category of a 
If taxonomy identified by home>repair>airconditioning or 
't^l household>equipment>airconditioning>repair, or the like. 

Each category of a taxonomy must define the semantics, i.e. 
what the services in the category do, as well as the application 
program interface (API) used to communicate with the service 
25 providers, i.e. how to invoke the services. In order to provide 
such classifications, a canonical service description (CSD) may 
be used to describe each classification. The CSD provides a 
mechanism by which a service may be classified that is 
recognizable by all parties to the service brokerage transaction. 
30 That is, the CSD based classification is recognized by the 
service consumer, the broker, and the service providers. 

All services in a category must implement the canonical 
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service description for that category, although they may do more 
than is provided in the CSD, i.e. the CSD provides the minimum 
requirements for a service to be classified into a corresponding 
category. 

5 The use of CSDs that define the minimum requirements for 

services in a category provides a mechanism that facilitates 
searching of taxonomies at runtime. At runtime there is little, 
if any, interaction with a human user. Thus, in order to perform 
searching of categories in a taxonomy to identify services, a 

10 mechanism is needed by which to perform the search. This 
mechanism is the CSD. 

With the present invention, an automatic search of the 
categories in a taxonomy is possible by searching for a matching 

\| CSD, i.e. a CSD that matches a requested CSD or provides minimum 
requirements corresponding to requirements of a search query, 

yj 

d Such a search does not require input from a human user at runtime 
'Zl because each service categorized into a particular category is 
- guaranteed to implement at least the functionality and APIs 

designated by the CSD of that category. 
2D Figure 5 illustrates an exemplary canonical service 

gl description. The canonical service description shown in Figure 5 
is provided in the extensible markup language (XML) and 
represents an example cannonical service description for a stock 
quote service. The mechanism used for describing the cannonical 
25 service description is the web services description language 
(WSDL) , with CSD related extensions. The use of WSDL is 
standard, defining the "reusable" portion of a web service over 
the Simple Object Access Protocol (SOAP) . 

There are two main elements in the file that distinguish 
30 this file as a CSD description from other uses of WSDL to define 
"reusable" portions of a service description. These two elements 
are both defined within the CSD namespace extension to the WSDL 
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language. CSD-related elements are inserted into a WSDL using 
the standard extension mechanism defined in the WSDL language. 

The example shown in Figure 5 defines a StockQuoteBinding 
CSD, for use in defining the standard web services interface 
definition for stock quoting. Organizations may use this CSD as 
the template for defining ''API standard^' stock quote web 
services . 

The csd: testService element defines the specific service 
information of a service that provides validatable results. If a 
developer wishes to test an implementation of the stock quote web 
service, as will be discussed in greater detail hereafter, the 
developer may invoke the web service implementing the 
StockQuoteBinding and compare the results of this service by 
invoking the cannonical test service for the CSD identified by 
the service definition described in the csd: testService element. 

The csd: categorization element defines the category (s) in 
the taxonomy (s) in which implementations of the CSD should be 
placed. In this case, web services implementing this CSD are 
eligible to be inserted into the equitylnstruments taxonomy, 
defined by the f inancialWebServicesStandards organization, and 
into the category equityInstruments>equities>quotes> 
nonRealTimeQuotes . 

The CSD shown in Figure 5 is for illustration purposes only 
and is not intended to be limiting in any way. CSDs in 
accordance with the present invention may include other 
information in addition to, or in replacement of, the information 
shown in Figure 5 without departing from the spirit and scope of 
the present invention. 

The CSD provides a description of the service that is 
provided in such a manner as to be cognizable to the service 
consumer. The CSD includes service descriptions that are both 
human readable and machine parsable. For example, the CSD 
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service descriptions may be implemented in the extensible markup 
language (XML) which is parsable by machines, a word processor 
formatted document, or the like. The CSDs also describe non- 
functional requirements, such as security and authentication 
assumptions, and other prerequisites considered to be common to 
all services in the category. 

The CSD for each category is related to that of the category 
one level up. However, the semantics of a given service may 
differ from the next level up in important ways. That is, a 
specialization of a service at the next level down in the 
hierarchy may implement the same function, but do so in a very 
different way with different argument characteristics and 
different returned results from that of the next level up. Thus, 
the CSD describes how the services in the category differ from 
those in a parent category and any sibling categories in the 
taxonomy. 

The CSDs may provide tests by which membership in the 
category may be determined. These tests may be provided as 
executable tests in XML, or other similar executable languages, 
for example. That is, when a service provider attempts to 
register its service with a broker, the broker may determine 
whether or not the service meets the minimum requirements of a 
chosen category based on the tests included in the corresponding 
CSD. The CSD tests allow a broker to objectively and 
automatically determine that a service satisfies the requirements 
for being included in a particular category. 

The CSD test identifies messages that may be sent to the 
service provider and corresponding reply message that should be 
received from the service provider. These messages may be 
directed to various aspects of the service that is provided by 
the service provider. For example, these messages may be 
directed to security issues, privacy issues, and communication 
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protocols used by the service. 

When a service provider requests to have their service 
registered in a particular category of a taxonomy supported by a 
service broker, the service provider sends a request to the 
service broker identifying the category that the service is 
intending to be registered in as well as the APIs used by the 
service. The API description may include, for example, method 
names, parameter names, parameter types, executable API test 
suites, and the like, such that the service broker can determine 
whether the service implements what it claims to implement before 
registering it in a given category. 

Upon receiving the registration request from the service 
provider, the service broker performs the tests associated with 
the CSD of the selected category. That is, the service broker 
sends the messages included in the tests to the service provider 
and monitors the reply messages received. The sending of the 
messages to the service provider is performed in view of the 
method name, parameter names, parameter types, etc. Included in 
the API .description of the registration request. The service 
broker then matches the reply messages received to the "correct" 
reply messages included in the CSD test. If there is a match of 
the test messages, the service is verified as meeting the 
requirements of the CSD and the service is permitted to be 
registered in the selected category. 

If the service implements exactly the API specified in the 
category's canonical service description, the service description 
included with the registration request need not provide any 
further tests. However, any additional functionality beyond the 
API specified in the CSD may be accompanied by additional tests. 
These additional tests are implemented in the same way as the CSD 
tests to confirm that the service provides the functions 
identified. 
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Security constraints on some services may require that the 
taxonomy server be given special certificates or other 
certification information as part of registration so that it can 
execute the tests. In situations that call for extreme security, 
authentication or encryption, the taxonomy server may only 
receive exceptions in response to the tests. Even in that case, 
though, it should receive the correct exceptions, i.e. the 
exception received should indicate that the service is present 
but not responding due to inadequate authentication. 

If a service fails one or more of the tests in the CSD, or 
additional tests included in the registration request, the 
service provider may be provided with a report of which tests 
were satisfied and which tests failed. In this way, the service 
provider is provided with information by which the operator of 
the service provider may modify their service description and 
service functionality to conform to the requirements of the 
selected category. 

Thus, the use of canonical service descriptions provides a 
mechanism by which services may be categorized and verfied to 
meet the minimum requirements of the particular categories in 
which they are placed. Thus, if a service is to be registered 
with multiple taxonomies, the service is guaranteed to meet the 
minimum requirements of each category in which it is registered. 

In order for the brokerage mechanism of the present 
invention to operate, service providers must first register with 
one or more brokers in accordance with the taxonomies supported 
by those brokers. In determining with which brokers to register, 
the service provider must balance the service consumer's desire 
to have a ''target rich'' environment with the need for the service 
provider to be ''seen" in the right places. The balance of these 
two concerns results in the need for a service provider to 
examine the taxonomies supported by various brokers and register 
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the service with those brokers, and in the appropriate 
categories, where service consumers are likely to look for the 
service . 

As an example to illustrate the need to register with 
5 multiple brokers, consider a fictional small retail flower e- 

business in Des Moines, Iowa named ''CornFlowers.com," as shown in 
Figure 6. In addition to the general flower retailing business, 
CornFlowers.com specializes in growing and selling a number of 
varieties of orchids. 
10 CornFlowers.com participates as a buyer in at least two B2B 

e-business markets. It buys most of its standard types of 
flowers over a B2B link with its primary wholesaler and it buys 
specialty items (e.g., accessories, balloons, vases and planters) 
S| from a florist supplies broker. 

rjl5 CornFlowers.com also wishes to provide flower selling e- 

^1 business services to clients via the Internet. CornFlowers.com 

m . . 

■p . participates as a supplier in two industry-oriented brokers 

- (FTD.com's industry broker and SFlowers . com' s industry broker). 

U CornFlowers.com also wants to provide flower selling e-business 

CEO services to other clients outside of the ''big" flower brands 

(FTD, 5 FLOWERS ) . As a result, CornFlowers.com wants to appear in 
flower-related e-marketplaces (e.g., for weddings and funerals) 
in the Des Moines area. CornFlowers.com is also active in 
Orchids of America, a special interest group concerned with the 
25 growing and marketing of orchids. It is in CornFlower . com' s 

business interest to be visible as a provider of B2B services in 
this group as well. 

Note that CornFlower . com' s business success depends upon 
being listed in appropriate, but different, categories in several 
30 taxonomies supported by several different brokers. 

CornFlower.com wishes to be listed geographically in FTD and 
5FL0WERS. It wishes to be listed by flowers in the Des Moines 
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broker, and wishes to be listed by its specialized orchid 
varieties in the orchid broker. As a result, CornFlower . com 
registers its service in the f lowers . FTD . com>Ret ail >USA>IOWA>Des 
Moines category of the taxonomy supported by the FTD broker, the 
localYellowPages .org>Florists>DownTown category in the taxonomy 
supported by the "AllThingsDesMoines" services yellow pages 
broker, and the OOA. org>Retail>Midwest>Iowa category in the 
Orchids of America broker. 

In registering its service with a broker, the service 
provider submits a registration request to the broker. The 
registration request includes a service description, an API 
designation, and any other non- functional information pertinent 
to the invoking of the service. The API designation and non- 
functional information may be designated in terms of a model 
description. The model description identifies the address by 
which to contact the service provider, the protocols used to 
communicate with the service provider, security used by the 
service provider, authentication and privacy, as well as any 
other non -functional information. 

The registration request further includes an indication of the 
categories within the taxonomies of the broker in which the 
described service may be categorized. 

The determination whether to allow the registration in the 
requested categories may be made based on minimum requirements of 
the category, as designated by the corresponding canonical 
service description, in order to make sure the service to be 
registered is in conformance with other services already 
registered under the categories. These minimum requirements may 
include, for example, security issues, privacy issues, 
communication protocols, and the like, which are designated in a 
CSD. 

The determination of whether or not the service to be 
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registered meets the minimum requirements may be made by a human 
administrator of the service broker or automatically by the 
service broker itself based on canonical service description 
tests, as described above. If a service to be registered is 
identified as meeting the CSD requirements of a particular 
category, the service may be registered under that category. If 
the service to be registered is identified as meeting the CSD 
requirements of more than one category, the service provider may 
be provided with the option to register under one or more of the 
categories . 

If a service to be registered is not identified as meeting 
the requirements of any category in the supported taxonomy, the 
service provider may be provided with the option to request that 
the service broker define a new category in which the service may 
be classified. The administrator of the service broker may then 
decide whether or not to support the new classification and 
inform the service provider of the decision. If the 
administrator agrees to define a new classification, the service 
proviTier ^raay then register its service with the service broker in 
a manner described above. Otherwise, the service provider will 
be unable to register its service with that particular service 
broker. 

Once a service is registered with a service broker in the 
manner described above, the service is included in the list of 
services associated with the designated category of the service 
broker. By stating that the service is included in the list of 
services what is meant is that the service description and model 
submitted by the seirvice provider is stored in memory in 
association with the categories in which the service was 
registered. 

The service consumer may invoke a requested service by first 
contacting a service broker to identify a provider of the 
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service, obtain the model description for the service provider, 
and then contact the service provider based on the model 
description to thereby obtain the requested service. In 
contacting the service broker, the service consumer sends a 
request for a service to the service broker. The service 
consumer may be associated with the service broker such that the 
request is directed specifically at the service broker, or the 
service request may be broadcast across the network 102 such that 
service brokers having registered service providers meeting the 
requirements of the service request may respond accordingly. 

The service request uses the same service description 
semantics used by the service providers when submitting their 
services to the service brokers for registration. The service 
request is parsable by the service broker to thereby identify the 
categories in the supported taxonomy that may have registered 
services meeting the service request requirements. For example, 
the service request may include an identification of a 
taxonomy/category pair that is requested or may include a CSD 
description of a service requested. 

When the service broker receives the service request, the 
service broker traverses the supported taxonomy to identify one 
or more service providers that may provide the requested service. 
For example, if a taxonomy/ category pair is identified in the 
service request, only those services categorized into the 
identified category are investigated to determine if they match 
the requested service. Alternatively, if only a CSD description 
is provided, the entire taxonomy must be traversed to identify a 
service having the requested CSD. 

Figure 7 is an exemplary diagram illustrating the 
hierarchical levels traversed in a service broker to identify an 
e-business service provider in accordance with the present 
invention. As shown in Figure 7, a service broker 710 hosts a 
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taxonomy registry 720. The taxonomy registry 720 identifies the 
various l...n taxonomies supported by the service broker 710. 
The root node 730 represents the root of the 0...n categories 740 
within the taxonomy. Each categoiry 740 contains 0,.,n service 
5 descriptions 750 identifying registered services in that 

category. The service descriptions 750 have associated model 
descriptions 760. The model descriptions 760 provide the 
necessary information for contacting a service provider 770. 

Thus, when searching registered services on a service broker 
10 710, the service broker traverses each taxonomy corresponding to 
the taxonomy root nodes 73 0 in the taxonomy registry 720 and 
identifies a category 740 meeting the criteria of the service 
request. Alternatively, this crawling of the taxonomy may be 
Ul based on an identified taxonomy/category pair in the service 

^}::15 request received. The service broker 710 then identifies one or 
01 more service providers that provide the requested service based 

on the registered service descriptions 750 within the identified 
category 740. Alternatively, if non-uniform accepted service 
r| descriptions are used, the service broker 710 may return all 

;|20 service descriptions registered under a compatible category. The 
h-^ associated model description 760 may then be used by the service 

consumer to contact the service provider 770. 

It is possible that there may be a plurality of registered 
services that meet the requirements of the service request. In 
25 such an instance, one of the compatible services may be chosen in 
either a specified or arbitrary way. For example, the service 
consumer may be presented with each of the possible candidates 
and allowed to select the service provider that it wishes to use. 
The service providers may be ranked based on prior use of the 
30 service providers and thus, a higher ranked service provider may 
be chosen. Service providers may be selected based upon 
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priorities assigned to non-functional descriptive information 
included in either the service description or the model 
definition. Alternatively, a service provider may be selected 
randomly. Any mechanism by which one service provider may be 
5 chosen from a plurality of compatible service providers may be 
used without departing from the spirit and scope of the present 
invention. 

As mentioned above, the identification of a service provider 
capable of providing the desired service may be performed at 
10 runtime. At runtime, there is no human judgment available to 

determine if a service matches a required business need. This is 
not a problem with the present invention since the taxonomy 
architecture of the present invention ensures that services in a 

=11 

%! particular classification will at least satisfy the business 
:f| needs associated with the corresponding CSD's minimum 
;i| requirements. Therefore, an automatic identification of a 
''i'^ compatible service provider is possible based on the 

classification scheme of the present invention. No human 

intervention is required. 
21 Thus, with the present invention, a service broker acts as a 

%l mediary between service consumers and service providers. Based 

on the categorization architecture of the present invention, a 

service registered with the service broker may be automatically 

identified based on the criteria in a service request, and 
25 corresponding contact information may be provided to the service 

consumer so that the service consumer may contact the service 

provider to obtain the desired service. 

Figure 8 is a flowchart outlining an exemplary operation of 

the present invention when registering a new service with a 
30 broker. As shown in Figure 8, the operation starts with the a 

registration request being received (step 810) , The registration 

request includes a service description and model description. A 



RSW9-2000-0103-US1 24 

determination is made as to whether the service should be added 
to the registered services under the requested classifications 
(step 820) . This determination may include determining if the 
service description of the service to be registered satisfies the 
5 minimum requirements of the requested classifications in the 
taxonomies supported by the service broker, as identified by 
corresponding canonical service descriptions. If the 
determination is that the service fits the canonical service 
description for the requested classification, the service 
10 description and model description are added to the list of 

services associated with the selected classification categories 
(step 830) . 

'^f If the service description is not to be added to any of the 

%l requested classification categories, the service provider may be 
provided with the option to request a new category to be created 
^il (step 840) . If the service provider does not request a new 

j;^ category, the operation ends. If the service provider does 

request a new category, a determination is made as to whether or 
U;, not a new category should be added (step 850) . If so, a new 
If) category is generated and added to the supported taxonomy (step 
r| 860) . If a new category is not to be added, the operation ends. 

Figure 9 is a flowchart outlining an exemplary operation of 
the present invention when processing a service request from a 
service consumer. As shown in Figure 9, the operation starts 
25 with receiving a service request from a service consumer (step 
910) . The request includes a service description of the 
requested service. The service description in the service 
request is parsed (step 920) and the taxonomies supported by the 
service broker are searched to determine if any registered 
30 services meet the service description in the se2rvice request 
(step 930) . If not, a "no services available" message is 
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returned to the service consumer (step 940) . If one or more 
services are identified, a determination is then made as to 
whether more than one service is identified (step 950) . If so, 
one of the services is selected based on one or more selection 
schemes (step 960) . Thereafter, or if only one service is 
identified, the model definition for the identified service is 
provided to the service consumer so that the service consumer may 
contact the service provider (step 970) . The operation then 
ends . 

Thus, the present invention provides a unified architecture 
for classifying services into taxonomies, and categories within 
these taxonomies, supported by service brokers in a network. The 
unified architecture makes use of canonical service descriptions 
for purposes of classification and to assure that services meet a 
minimum requirement for respective categories within the 
taxonomies. In addition, the canonical service descriptions may 
provide executable tests which may be used to verify a service as 
meeting minimum requirements for a classification as well as 
provide a mechanism by which compatible classifications may be 
identified to a service provider. 

Based on this architecture, service consumers may send 
service requests to service brokers in order to identify those 
service providers that are capable of providing a desired 
service. The service brokers may then provide contact 
information to the service consumer such that the consumer may 
contact the service provider to obtain the desired service. 

As a further embodiment of the present invention, the 
canonical service description tests describe above may be used as 
a mechanism for identifying categories in which a service may be 
registered. For example, consider the scenario of a service 
provider sending a registration request to a service broker 
identifying a particular category in which a particular service 
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is to be registered. If the service fails the CSD tests required 
for registration in the selected category, the service broker may 
look to other similar categories to determine if the service may 
meet the CSD tests of these other similar categories. 
5 For example, the service broker may look to sibling, parent 

and/or child categories, within a certain range of the selected 
category in the taxonomy. The CSD tests associated with these 
categories may be applied to the service that is to be registered 
and a determination as to whether the service satisfies the 

10 minimum requirements of these categories may be made. If the 
service does meet the minimum requirements of one or more of 
these categories, these categories may be identified to the 

^^1 service provider so that the service provider may be given the 

C| option to select one of these categories for registration of the 

fS service. 

•it- 

f|| It is important to note that while the present invention has 

been described in the context of a ftilly functioning data 

- processing system, those of ordinary skill in the art will 

f't 

appreciate that the processes of the present invention are 
IIP capable of being distributed in the form of a computer readable 
:SJ medium of instructions and a variety of forms and that the 

present invention applies equally regardless of the particular 
type of signal bearing media actually used to carry out the 
distribution. Examples of computer readable media include 
25 recordable- type media such a floppy disc, a hard disk drive, a 
RAM, CD-ROMs, and transmission- type media such as digital and 
analog communications links. 

The description of the present invention has been presented 
for purposes of illustration and description, and is not intended 
30 to be exhaustive or limited to the invention in the form 

disclosed. Many modifications and variations will be apparent to 
those of ordinary skill in the art. The embodiment was chosen 
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and described in order to best explain the principles of the 
invention, the practical application, and to enable others of 
ordinary skill in the art to understand the invention for various 
embodiments with various modifications as are suited to the 
particular use contemplated. 



